home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
ospf
/
ospf-minutes-92mar.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
10KB
|
193 lines
This is a rough draft - Megan 04/06/92
Hi. Here are the minutes of the last OSPF Working group meeting. I
have referenced the handwritten slides that people presented;
unfortunately to see them you'll have to get a copy from the
proceedings. It reads pretty well without them though...
John
------------------------ cut here ----------------------------------
OSPF WG minutes: March 92 meeting
The OSPF Working Group met at the March 1992 IETF in San Diego. The
minutes from that meeting follow.
The meeting began with an announcement that IP multicast has been
assigned an 802.5 functional address. This affects OSPF over 802.5,
since many OSPF control packets (Hellos, etc.) are sent as IP
multicasts. The functional address assignment will be documented in
a short RFC, probably written by Steve Deering. It was suggested
that to aid in the transition from the 802.5 broadcast address to
the new functional address, a configuration knob be provided in OSPF
implementations to select between broadcast/functional address. In
any case, by the principle of "be liberal in what you receive", you
should not reject a packet whose link level destination is the
broadcast if you are instead expecting the functional address (this
would enable a staged transition to the functional address, where
you first enable reception of the functional address, and then in
some future release start sending it).
There are now a number of OSPF documents that will soon be ready for
publication as RFCs: reissues of the base spec and the OSPF MIB, the
OSPF Trap MIB, and the OSPF NSSA document. It is likely that these
documents will want to reference each other, which may cause some
logistical problems since you can't reference Internet Drafts (maybe
they'll have to be issued as a set). In any case, it was decided to
delay the publication of these documents until there were at least
two interoperable implementations.
During the main part of the meeting, the following issues were
discussed:
o We reviewed proposed changes to the base OSPF spec (RFC 1247).
These changes are: a fix to a bug found in certain virtual link
configurations, updating the TOS representation to include the
new monetary cost bit, making summarization of routes into stub
areas optional and an optimization to summarizing routes into
transit areas. At the previous IETF a different fix to virtual
link problem was discussed and rejected due to its complexity.
The present fix, suggested independently be several people, is
much simpler. Part of the fix involves removing the ability to
assign a cost of LSInfinity to router interfaces. The fans of
Strong TOS (e.g., Milo and John Lekashman) were against this.
John Moy was assigned the action item of further explaining why
LSInfinity was a problem, and then negotiating with Milo and
John. Fred Baker also mentioned that he had come across a
situation where he wanted to condense inter-area routing
information (not just intra-area, as specified in the current
[Page 1]
spec), but that the provision making summarization into stub
areas optional would serve just as well.
The proposed changes to RFC 1247 will be published shortly as an
Internet Draft, followed by a revised version of the OSPF spec.
All changes are backward compatible; there will be no need to
increase the OSPF version number.
o Rob Coltun presented a collection of backward-compatible
additions to the OSPF MIB. These additions included three
variables to deal with OSPF Database Overflow: LSDBHiWater
(read-only; the largest number of LSAs that have ever been in
the router's database), LSDBOverflowWarning (read/write; when
the number of LSAs hits this number a trap is generated) and
LSDBLimit (read/write; when the number of LSAs hits this number
the router takes further action to limit the size of the
database as specified in a document to be written by John Moy).
Also, a new table for type 5 external-LSAs is to be included,
since in the current MIB it is not clear in which area
ospfLsdbTable these LSAs should be reported. Fred Baker
explained that, in order to be backward compatible, it would
still be legal to report the type 5 externals LSAs in the old
ospfLsdbTable.
It was also noted that there should be two new ospfLsdbType
values: 6 (for the group-membership-LSAs) and 7 (for the LSAs
used by NSSA areas). In addition, since the interface cost
LSInfinity is being removed, the comment in the
ospfIfMetricMetric entry ("The value FFFF is distinguished to
mean 'no router via this TOS'") should be removed.
Jeff Honig brought up a list of MIB variables that were named
inconsistently. According to Fred Baker, we do not have to
maintain the ascii text representation of MIB variables to
qualify for backward-compatibility, even though this may be an
inconvenience to certain network management stations. Rob, Fred
and Jeff are to go though the MIB to see which variables warrant
renaming.
o Rob Coltun summarized the state of the OSPF Trap MIB (see Slide
2) which is very near to being finalized. There was some
discussion on the best strategy for inhibiting traps when a
router first starts, with the arguments for and against
inhibiting traps on a per-interface basis being rehashed once
again.
o Jeff Honig brought up the issue on how the OSPF MIB could handle
multiple instances of OSPF running in the same box. While there
[Page 2]
is a straightforward technical solution to this problem
(basically adding another index to all the MIB's tables), this
is not backward-compatible and was viewed by several people as
making the MIB overly complicated. Fred Baker suggested that
this was a larger issue than just for OSPF, and suggested that
we pass the problem (namely, how to monitor several instances of
a protocol) on to the network management working group.
o Rob Coltun and Vince Fuller have completed a document describing
the OSPF Not-so-stubby-area (NSSA) option, adding a motivational
section to the outline that was presented the previous meeting
(Santa Fe), and completing the technical details. Rob presented
an overview of the NSSA support, together with some of the more
non-obvious details (see slide 3). Basically, NSSAs are a new
type of area, similar to OSPF stub areas in that they do not
handle type 5 external-LSAs (and so routers internal to these
areas require less resources). However, NSSAs are capable of
importing external information of their own, which will be
converted to normal type 5 LSAs at the NSSA boundary. This
enables, for example, RIP clouds to be hung off of NSSA areas.
Discussion centered upon whether we should be multiplexing
several functions onto a single OSPF options bit (now that they
are getting scarce), and the correct way to model the
translation of external information that takes place at the NSSA
boundary.
o Rob Coltun and Jeff Honig presented a proposal for another new
OSPF option, which they called the PRI (Peripheral Router
Interconnect) option (see Slides 4-7). This would provide a way
to configure a set of distinguished OSPF routers, which would
automatically discover each other and then be able to exchange
additional information formatted as new LSA types. Jeff Honig
explained an application of this whereby the PRI routers could
exchange AS path information, obviating the need for IBGP. Rob
and Jeff intend to write this up in more detail.
o Osmund deSouza led a discussion on how to run OSPF over Frame
relay (slides 9-12). One concern was that, since in real Frame
relay networks you are unlikely to have full mesh connectivity
for PVCs, the NBMA model does not apply. In these cases, the
Frame relay would have to be treated as a collection of point-
to-point links. A number of people thought that it might be
possible to model Frame relay as a collections of some number of
NBMAs and serial lines, to achieve maximum efficiency (slide
11). To aid in this, Fred Baker thought that the Frame relay MIB
already had the provision to allocate particular sets of PVCs to
particular IP networks.
[Page 3]
People agreed that, in order to guarantee interoperability, a
document is needed to discuss the options for running OSPF over
Frame relay. This document could also discuss ways of detecting
configuration errors (e.g., when some routers are configured for
NBMA support and others are configured to see the Frame relay as
serial lines).
Osmund also discussed a possibility whereby routers connected to
a Frame Relay network could be grouped so that the groups were
fully interconnected (slide 12). It was thought that the NBMA
and Designated Router functions could be generalized to optimize
running OSPF over such a configuration, although exactly how to
implement this was unclear.